-
Notifications
You must be signed in to change notification settings - Fork 850
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stabilize ExceptionEventData #6795
Stabilize ExceptionEventData #6795
Conversation
@@ -18,13 +17,15 @@ | |||
public interface ExceptionEventData extends EventData { | |||
|
|||
/** | |||
* Returns a new immutable {@link ExceptionEventData}. | |||
* Returns a new immutable {@link io.opentelemetry.sdk.trace.data.ExceptionEventData}. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this shouldn't require being fully qualified, I don't think. I'd revert the fully-qualified classname changes here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dang it, sorry I will just use the class name and remove the fully-qualified classname.
@AutoValue | ||
@Immutable | ||
abstract class ImmutableExceptionEventData implements ExceptionEventData { | ||
abstract class ImmutableExceptionEventData | ||
implements io.opentelemetry.sdk.trace.data.ExceptionEventData { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should be importable, and not need to be fully-qualified
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #6795 +/- ##
============================================
+ Coverage 90.12% 90.49% +0.37%
- Complexity 6546 6598 +52
============================================
Files 728 731 +3
Lines 19702 19735 +33
Branches 1935 1938 +3
============================================
+ Hits 17756 17859 +103
+ Misses 1347 1283 -64
+ Partials 599 593 -6 ☔ View full report in Codecov by Sentry. |
…e a little for removing misleading comments from copy paste.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few discussion points
sdk/trace/src/main/java/io/opentelemetry/sdk/trace/data/ExceptionEventData.java
Show resolved
Hide resolved
+++ NEW INTERFACE: io.opentelemetry.sdk.trace.data.EventData | ||
+++ NEW SUPERCLASS: java.lang.Object | ||
+++ NEW METHOD: PUBLIC(+) STATIC(+) io.opentelemetry.sdk.trace.data.ExceptionEventData create(io.opentelemetry.sdk.trace.SpanLimits, long, java.lang.Throwable, io.opentelemetry.api.common.Attributes) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jkwatson its odd for the create method to accept SpanLimits
as an argument. Normally the application of limits is handled in SDK internals. We can see this pattern play out in the EventData.create
contract:
static EventData create(
long epochNanos, String name, Attributes attributes, int totalAttributeCount)
The attributes are provided with an additional totalAttributeCount
indicating how many attributes were originally present.
The reason we do it differently for ExceptionEventData
appears to be because ImmutableExceptionEvent#getAttributes()
doesn't compute the attributes until it is called (and then it memoizes them), preventing additional allocations on the hot path.
Not sure there's a way to avoid SpanLimits
being passed as an argument if we stick with that argument.
+++ NEW SUPERCLASS: java.lang.Object | ||
+++ NEW METHOD: PUBLIC(+) STATIC(+) io.opentelemetry.sdk.trace.data.ExceptionEventData create(io.opentelemetry.sdk.trace.SpanLimits, long, java.lang.Throwable, io.opentelemetry.api.common.Attributes) | ||
+++ NEW METHOD: PUBLIC(+) ABSTRACT(+) io.opentelemetry.api.common.Attributes getAdditionalAttributes() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Upon closer inspection, I find this method strange. The resulting ExceptionEventData
interface has the following methods:
getAttributes()
: default implementation returnsgetAdditionalAttributes()
provided by user +exception.*
attributes following semconv.getAdditionalAttributes()
: default implementation returns only additional attributes provided by the user.
Seems odd to have a special accessor for getAdditionalAttributes()
. I assume that consumers of this want to do something like: if(event instanceOf ExceptionEventData) serialize(((ExceptionEventData) event).getException())
If they want o split out the exception attributes from additional attributes, can do so with getAttributes().toBuilder().removeIf(attributeKey -> attributeKey.getKey().startsWith("exception")).build()
.
Do we really need the special getAdditionalAttributes()
accessor?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm. good eye on double checking the original API for this. Maybe we're not quite ready to stabilize, if we're unsure of the final API? I agree the creational patterns for this are currently strange and not user-friendly. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can still stabilize, but cut out the getAdditionalAttributes()
method. The point I make here about SpanLimits
as a constructor argument is an implementation detail. We can remove it as a parameter with the only difference being that we compute the exception.*
attributes on the calling thread instead of on a background thread, which seems pretty reasonable / expected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you agree, I can either push some commits to this PR, or provide some more complete guidance to @vasantteja on how to proceed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm totally ok with your suggestion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jack-berg I understand that we should remove getAdditionalAttributes()
and SpanLimits
from the implementation. Your suggestion to make this similar to EventData makes sense to me. The reason behind this is that the caller can retrieve the additional attributes using this call getAttributes().toBuilder().removeIf(attributeKey -> attributeKey.getKey().startsWith("exception")).build();
. Did I get this right, or am I missing anything? If yes, I can make the changes suggested.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You've got it.
The exception.*
attributes will need to be computed in SdkSpan
, rather than in ImmutableExceptionEventData
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jack-berg I finally wrapped my head around this and have an implementation. I cut out the attribute computation in the ImmutableExceptionEventData
and I moved them to SdkSpan
. I added a little bit of logic to shrink the exception messages if maxLength attribute is turned on in SpanLimits
. Let me know if this aligns with your thinking.
Co-authored-by: jack-berg <[email protected]>
sdk/trace/src/main/java/io/opentelemetry/sdk/trace/SdkSpan.java
Outdated
Show resolved
Hide resolved
sdk/trace/src/main/java/io/opentelemetry/sdk/trace/data/ImmutableExceptionEventData.java
Outdated
Show resolved
Hide resolved
sdk/trace/src/main/java/io/opentelemetry/sdk/trace/data/ImmutableExceptionEventData.java
Outdated
Show resolved
Hide resolved
sdk/trace/src/main/java/io/opentelemetry/sdk/trace/SdkSpan.java
Outdated
Show resolved
Hide resolved
…bleExceptionEventData.java Co-authored-by: jack-berg <[email protected]>
…bleExceptionEventData.java Co-authored-by: jack-berg <[email protected]>
Co-authored-by: jack-berg <[email protected]>
I pushed a small commit to capture the total number of attributes added (in case any were filtered to conform to SpanLimits), and to remove unused methods. Looks good to merge to me! |
+++ CLASS FILE FORMAT VERSION: 52.0 <- n.a. | ||
+++ NEW INTERFACE: io.opentelemetry.sdk.trace.data.EventData | ||
+++ NEW SUPERCLASS: java.lang.Object | ||
+++ NEW METHOD: PUBLIC(+) STATIC(+) io.opentelemetry.sdk.trace.data.ExceptionEventData create(long, java.lang.Throwable, io.opentelemetry.api.common.Attributes, int) | ||
+++ NEW METHOD: PUBLIC(+) ABSTRACT(+) java.lang.Throwable getException() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
This Change
I promoted both the interface and implementation to data package adhering to the package structure inside the internal implementation. Let me know your thoughts. Sorry for opening another pr when we have another pr. This resolves 6630